Amazon Redshift Serverless で Redshift マネージド VPC エンドポイントを作成して任意の場所から名前解決できるか確認してみた
Amazon Redshift Serverless で Redshift マネージド VPC エンドポイントをとりあえず作って名前解決してみました
コンバンハ、千葉（幸）です。
Amazon Redshift （Serverless 含む）では Redshift マネージド VPC エンドポイントという機能があり、Redshift クラスター・ワークグループへの VPC をまたいだアクセスを簡単に構成できます。
Redshift マネージド VPC エンドポイントによりインターフェース型の VPC エンドポイントが作成され、配置サブネットの範囲の中で自動的に IP アドレスが採番されます。
以下のようにオンプレミスからのアクセスを想定した際に、果たしてこのエンドポイントの IP アドレスは任意の場所から引けるのか？（VPC 内の DNS サーバーからでないと引けない・などないか？）というのが気になりました。
「普通のインターフェース型の VPC エンドポイントと同じだったら任意の場所から引けるよな……？」などと思っていたのですが、論より証拠ということで実際に試してみました。
まとめ
- Redshift マネージド VPC エンドポイントのエンドポイント URL は任意の場所から名前解決できるし、プライベート IP アドレスを返してくれる
- 付随して学んだこと
- Redshift Serverless のワークグループを作成すると ENI がたくさんできる
- Redshift Serverless のワークグループを作成するとマネージドでない VPC エンドポイントもあわせて作成される
今回検証する構成
確認したいポイントは Redshift マネージド VPC エンドポイントの名前解決だけなので、最低限の構成で組んでみます。
結果が分かりやすくなるよう、以下のように VPC を分けています。（同一の VPC に配置することもできます。）
- Redshift Serverless を配置する VPC：
172.31.0.0/16 - Redshift マネージド VPC エンドポイントを配置する VPC：
192.168.0.0/16
Redshift Serverless の構築
取り立てて特別なことはせず、サクッと構築します。手順は以下に詳しいですので、適宜ご参照ください。
出来上がった Redshift Serverless ワークグループはこちらです。test-wgという名称で作成しています。
この画面には写っていませんが、Redshift 処理ユニット (RPU) のベース容量は128 を設定しています。
トピックとしては以下のあたりです。
- ワークグループのエンドポイントが払い出される（デフォルトのエンドポイント）
- マネージドでない VPC エンドポイントが作成される
- Redshift マネージド VPC エンドポイントを利用したい場合は手動でワークグループに追加する
デフォルトのエンドポイントの名前解決をしてみる
今回の主旨である Redshift マネージド VPC エンドポイントでなく、まずはデフォルトのエンドポイントを名前解決してみます。
% dig test-wg.012345678910.ap-northeast-1.redshift-serverless.amazonaws.com @8.8.8.8 ; <<>> DiG 9.10.6 <<>> test-wg.012345678910.ap-northeast-1.redshift-serverless.amazonaws.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5581 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;test-wg.012345678910.ap-northeast-1.redshift-serverless.amazonaws.com. IN A ;; ANSWER SECTION: test-wg.012345678910.ap-northeast-1.redshift-serverless.amazonaws.com. 60 IN CNAME vpce-05b2047b3817e66f4-82r8kf35.vpce-svc-0655570395b135666.ap-northeast-1.vpce.amazonaws.com. vpce-05b2047b3817e66f4-82r8kf35.vpce-svc-0655570395b135666.ap-northeast-1.vpce.amazonaws.com. 60 IN A 172.31.37.103 ;; Query time: 127 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Aug 17 13:23:34 JST 2022 ;; MSG SIZE rcvd: 207
test-wg...から始まるエンドポイントは、マネージドでない VPC エンドポイントvpce-...のエイリアスとなっており（CNAME）、正式名のvpce-...を名前解決するとプライベート IP アドレスが返却されることが分かりました。
この VPC エンドポイントと Redshift マネージド VPC エンドポイント を混同しないように気を付けたいですね。
余談： Redshift Serverless により自動的に生成される ENI を確認してみた
Redshift Serverless により動的に ENI が生成される、という話を聞いていたのでその内訳を確認してみました。
なお、012345678910で表しているのがわたしの AWS アカウントです。そうでないアカウント番号は、AWS 側で所有するものです。
% aws ec2 describe-network-interfaces\
--filters Name=vpc-id,Values=vpc-0903631bbdee7fca5\ #今回 Redshift Serverless を配置した VPC には他のリソースがないためこのフィルタリング条件で充足する
--query 'NetworkInterfaces[].{
PrivateIpAddress:PrivateIpAddress,
AvailabilityZone:AvailabilityZone,
Name:TagSet[?Key==`Name`]|[0].Value,
Description:Description,
NetworkInterfaceId:NetworkInterfaceId,
Status:Status,
OwnerId:OwnerId,
RequesterId:RequesterId,
RequesterManaged:RequesterManaged
}'\
--output table
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| DescribeNetworkInterfaces |
+------------------+-------------------------------------------------+-------+------------------------+---------------+-------------------+------------------+-------------------+----------+
| AvailabilityZone | Description | Name | NetworkInterfaceId | OwnerId | PrivateIpAddress | RequesterId | RequesterManaged | Status |
+------------------+-------------------------------------------------+-------+------------------------+---------------+-------------------+------------------+-------------------+----------+
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-04b055dc8ed15b1cf | 012345678910 | 172.31.44.123 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-0cc920e6c2b356d7c | 012345678910 | 172.31.40.33 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-08a22e1a0fd5567ba | 012345678910 | 172.31.47.160 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-0668d1271eebb81d7 | 012345678910 | 172.31.39.70 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-08ffa3c94856a8352 | 012345678910 | 172.31.40.247 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-03e923795fcc90f03 | 012345678910 | 172.31.38.170 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-008633146b2f2de50 | 012345678910 | 172.31.34.82 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-006cc781e8e767dde | 012345678910 | 172.31.35.10 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-0b59eaac24ac74b7d | 012345678910 | 172.31.40.60 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-03a323fc216ba1366 | 012345678910 | 172.31.32.82 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-09bf7a8c733ff20b1 | 012345678910 | 172.31.45.215 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-05c1c6bcf356cf705 | 012345678910 | 172.31.44.23 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-04bf9e6eadf102fcc | 012345678910 | 172.31.37.11 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-058a1a60aeb31f2e8 | 012345678910 | 172.31.32.176 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-024fb21866a3a0a78 | 012345678910 | 172.31.47.104 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-0a84fbf19062ad594 | 012345678910 | 172.31.34.168 | amazon-redshift | True | in-use |
| ap-northeast-1a | RedshiftNetworkInterface | None | eni-01736458628949ec8 | 012345678910 | 172.31.35.75 | amazon-redshift | True | in-use |
| ap-northeast-1a | VPC Endpoint Interface vpce-05b2047b3817e66f4 | None | eni-081f8943b99a4c4a8 | 012345678910 | 172.31.37.103 | 727180483921 | True | in-use |
+------------------+-------------------------------------------------+-------+------------------------+---------------+-------------------+------------------+-------------------+----------+
マネージドでない VPC エンドポイント用に 1 個、それ以外に 17 個作成されていることがわかりました。後者に関しては、RPU で指定した値によって増減するそうです。（今回は 128 を指定しています。）
AZ が一つに偏っているのも少し気になったポイントです。
Redshift マネージドVPC エンドポイントの作成
先述の通りRedshift マネージドVPC エンドポイントをワークグループに追加しました。その詳細画面が以下です。今回はtest-managed-vpceという名称で作っています。
こちらでも VPC エンドポイントが作成されています。以下の 2 種類があることを覚えておきましょう。
- Redshift Serverless ワークグループの作成により生成される VPC エンドポイント
- Redshift マネージドVPC エンドポイントの作成により生成される VPC エンドポイント
Redshift マネージドVPC エンドポイントの名前解決をしてみる
今回の本題です。先ほどと同じように名前解決を試みます。
% dig test-managed-vpce-endpoint-pua0reomi7x848lpbe8p.012345678910.ap-northeast-1.redshift-serverless.amazonaws.com @8.8.8.8 ; <<>> DiG 9.10.6 <<>> test-managed-vpce-endpoint-pua0reomi7x848lpbe8p.012345678910.ap-northeast-1.redshift-serverless.amazonaws.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24751 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;test-managed-vpce-endpoint-pua0reomi7x848lpbe8p.012345678910.ap-northeast-1.redshift-serverless.amazonaws.com. IN A ;; ANSWER SECTION: test-managed-vpce-endpoint-pua0reomi7x848lpbe8p.012345678910.ap-northeast-1.redshift-serverless.amazonaws.com. 60 IN CNAME vpce-04dfb06e84ac6da67-0powrfwo.vpce-svc-04db153f6c1504802.ap-northeast-1.vpce.amazonaws.com. vpce-04dfb06e84ac6da67-0powrfwo.vpce-svc-04db153f6c1504802.ap-northeast-1.vpce.amazonaws.com. 60 IN A 192.168.1.171 ;; Query time: 75 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Aug 17 13:15:16 JST 2022 ;; MSG SIZE rcvd: 247
こちらでもvpce-...のエイリアスになっていることが分かります。
最終的には VPC エンドポイントのインターフェースが持つプライベートIP アドレスが返却されています。パブリック DNS である8.8.8.8から引けているということは、（インターネット上に名前解決できる環境であれば）任意の場所から名前解決できます。やりたいことが満たせることが分かりました。
余談：Redshift マネージドVPC エンドポイントにより生成される ENI を確認してみた
こちらは先ほどと違い 1 つしかないのでそこまで見応えはありませんが、同様に ENI を確認してみました。
% aws ec2 describe-network-interfaces\
--filters Name=network-interface-id,Values=eni-016ad936144ca7e6c\
--query 'NetworkInterfaces[].{
PrivateIpAddress:PrivateIpAddress,
AvailabilityZone:AvailabilityZone,
Name:TagSet[?Key==`Name`]|[0].Value,
Description:Description,
NetworkInterfaceId:NetworkInterfaceId,
Status:Status,
OwnerId:OwnerId,
RequesterId:RequesterId,
RequesterManaged:RequesterManaged
}'\
--output table
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| DescribeNetworkInterfaces |
+------------------+-------------------------------------------------+-------+------------------------+---------------+-------------------+---------------+-------------------+----------+
| AvailabilityZone | Description | Name | NetworkInterfaceId | OwnerId | PrivateIpAddress | RequesterId | RequesterManaged | Status |
+------------------+-------------------------------------------------+-------+------------------------+---------------+-------------------+---------------+-------------------+----------+
| ap-northeast-1a | VPC Endpoint Interface vpce-04dfb06e84ac6da67 | None | eni-016ad936144ca7e6c | 012345678910 | 192.168.1.171 | 727180483921 | True | in-use |
+------------------+-------------------------------------------------+-------+------------------------+---------------+-------------------+---------------+-------------------+----------+
リクエスタの727180483921って何だろうと思っていたら、以下に登場していました。
2 つの VPC エンドポイントを確認してみる
最後に、せっかくなので以下の情報を取得してみました。
- Redshift Serverless ワークグループの作成により生成される VPC エンドポイント
- Redshift マネージドVPC エンドポイントの作成により生成される VPC エンドポイント
% aws ec2 describe-vpc-endpoints\
--filters Name=vpc-endpoint-type,Values=Interface\ #わたしの環境には他にインターフェース型のエンドポイントがないのでこのフィルタリングで充足している
--query 'VpcEndpoints[].{
ServiceName:ServiceName,
PrivateDnsEnabled:PrivateDnsEnabled,
VpcId:VpcId,
OwnerId:OwnerId,
VpcEndpointId:VpcEndpointId,
RequesterManaged:RequesterManaged
}'\
--output table
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| DescribeVpcEndpoints |
+--------------+--------------------+-------------------+----------------------------------------------------------------+-------------------------+-------------------------+
| OwnerId | PrivateDnsEnabled | RequesterManaged | ServiceName | VpcEndpointId | VpcId |
+--------------+--------------------+-------------------+----------------------------------------------------------------+-------------------------+-------------------------+
| 012345678910| False | True | com.amazonaws.vpce.ap-northeast-1.vpce-svc-0655570395b135666 | vpce-05b2047b3817e66f4 | vpc-0903631bbdee7fca5 |
| 012345678910| False | True | com.amazonaws.vpce.ap-northeast-1.vpce-svc-04db153f6c1504802 | vpce-04dfb06e84ac6da67 | vpc-0e4acafc38414468c |
+--------------+--------------------+-------------------+----------------------------------------------------------------+-------------------------+-------------------------+
取り立ててめぼしい情報はありませんでしたが、PrivateDnsEnabledがFalseであるのを見て「そう言われればそうだな」と思いました。（今回のサービス名を名前解決してパブリック IP アドレスを返却して欲しいことがないから、はじめからプライベート IP アドレスを返してくれる。つまりPrivateDnsEnabledをTrueにする必要がない。）
終わりに
Redshift マネージド VPC エンドポイントの名前解決について確認してみました。
任意の場所から名前解決でき、プライベート IP アドレスを返却してくれることが分かりました。今回は Redshift Serverless で試してみましたが、サーバレスでない Redshift でも同様かと思います。
Redshift マネージド VPC エンドポイントの活用例は以下をご参考ください。
導入を検討している方の参考になれば幸いです。
以上、 チバユキ (@batchicchi) がお送りしました。
